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1. Real Party in Interest 

The real party in interest is Global eXchange Services, Inc. (with a principle place of 
business in Gaithersburg, Maryland), which is the successor in interest in this patent 
application to the assignee of record, G.E. Information Services, Inc., a corporation under the 
laws of the State of Delaware. 



Evidence Appendix 

There are no related evidence that will directly affect, be directly affected by or have a 



ct, be directly artected by or have ; 
03/06/2086 JftDDOl 80008020 18023857 
the assignee, or the appellant' 



bearing on the present appeal, that are known to appellant, 

01 FCsHflH 

patent representative. The Evidence Appendix (Section 10), attached hereto, states "None 5 



00 OP 



WASH_1 556571.1 



Application No. 10/023,857 



Attorney Docket 88305-0142 



3. Related Appeals and Interferences 

There are no related appeals or interferences that will directly affect, be directly 
affected by or have a bearing on the present appeal, that are known to appellant, the assignee, 
or the appellant's patent representative. The Related Proceedings Appendix (Section 1 1), 
attached hereto, states "None". 

4. Status of Claims 

The present appeal is directed to claims 1-5, 10-14, 19-25, 27, 28, 33-39, 44-49, 51- 
58, 60-64, and 66-72, which are the claims under consideration. A copy of the pending 
claims 1-5, 10-14, 19-25, 27, 28, 33-39, 44-49, 51-58, 60-64, and 66-72 are attached herein in 
the Claims Appendix (Section 12). 

Claims 1, 10-13, 23-25, 27, 36-38, 49, 55-58, 64, and 70-72 are finally rejected under 
35 U.S.C. § 102(e) as being anticipated by U.S. Patent Application Publication No. 
2002/0099735 to Shroeder et al. (hereafter "Shroeder"). Claims 2-5, 14, 19-22, 28, 33-35, 39, 
44-48, 51-54, 60-63, and 66-69 are finally rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Shroeder in view of U.S. Patent 6,418,400 to Webber (hereafter 
"Webber"). Claims 13-14, 19-25, 27-28, 33-38, 58, 60-64, and 66-72 are rejected under 35 
U.S.C §101 as being directed to non-statutory subject matter. 

5. Status of Amendments 

Claims 1-73 were initially pending in the application filed on December 21, 2001. 
Claims 1,13, 27, 28, 33-39, 49, 58, 64, and 66-72 were amended and claims 6-9, 15-18, 26, 
29-32, 40-43, 50, 59, 65, and 73 were cancelled in an Amendment and Reply Under 37 
C.F.R. § 1.111 filed June 27, 2005, in reply to a first Office Action on the merits mailed on 
March 25,2005. 

A Notice of Appeal was filed on January 3, 2006 in response to a final Office Action 
mailed on September 2, 2005 which finally rejected claims 1, 10-13, 23-25, 27, 36-38, 49, 55- 
58, 64, and 70-72. 
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6. Summary of the Invention 

Claims 1,13, 27, 39, 49, 58, and 64 recite a computer implemented method, apparatus 
(system) and software for automatically transforming data between a self-describing markup 
language format and an Electronic Data Interchange (EDI) format. 

Figure 2 illustrates the overall system components. The outbound processing flow is 
described with respect to the customer application 230A which generates XML data 225A 
which is translated by a translator 205A to EDI data 235A which is sent to a trading partner 
240A. Further details of the outbound processing flow is described with respect to the 
flowchart disclosed in figure 4. See paragraphs [0069]-[0072]. 

The inbound processing flow is described with respect to a trading partner 240B 
sending EDI data 23 5B which is translated by a translator 21 OB into XML data 225B which is , 
then usable by the customer application 225B. Further details of the inbound processing flow 
is described with respect to the flow chart disclosed in figure 5. See paragraphs [0075-0081]. 

Figure 3 describes the process of the DTD generation which also creates the source 
and target data models that are a feature of the claimed invention. A standard data model 215 
is received by the DTD generator, wherein the standard data model contains all the elements 
needed for an EDI transaction. As would be understood by one skilled in the art, a data 
model specifies attributes of the elements that make up the data model and the relationships 
between the elements of the data model. 

The DTD generation process then generates an XML DTD which defines the 
elements, structures, and rules for marking up a given type of SGML document of which 
XML is one example. In addition, the DTD generator 200 generates a source data model 221 
and a target data model 222 which define the elements to which the source data and the target 
data can be assigned (for example, as variables in a memory array) so that mapping rules can 
be applied to data stored in the format of the source data model and/or the format of the target 
data model before the target data file (containing, for example, XML data 225A) is created. 
See paragraphs [0063]-[0066] of the specification. Exemplary rules for the creation of the 
source and target data models are disclosed in paragraphs [0067]-[0068]. During the DTD 
generation process, the user provides minimal input on, for example, the standard of EDI, the 
version of standard, the transaction set and the direction (inbound or outbound). Therefore, 
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the four components that are generated including the XML DTD, the source data model, the 
target data model, and a map component file (which defines the run time environment) 
account for the standard of EDI, the version of standard, the transaction set for each trading 
partner. 

7. Issues 

The issues on appeal are: (1) whether the examiner erred in rejecting claims 1, 10-13, 
23-25, 27, 36-38, 49, 55-58, 64, and 70-72 under 35 U.S.C. § 102(e) as being anticipated by 
Shroeder and claims 2-5, 14, 19-22, 28, 33-35, 39, 44-48, 51-54, 60-63, and 66-69 under 35 
U.S.C. § 103(a) as being unpatentable over Shroeder in view of Webber; and (2) whether the 
examiner erred in rejecting claims 13-14, 19-25, 27-28, 33-38, 58, 60-64, and 66-72 under 35 
U.S.C §101 as being directed to non-statutory subject matter. 

8. Argument 

I. It is respectfully submitted that the final rejection of claims 1, 10-13, 23-25, 
27, 36-38, 49, 55-58, 64, and 70-72 under 35 U.S.C. § 102(e) as being anticipated by 
Shroeder and claims 2-5, 14, 19-22, 28, 33-35, 39, 44-48, 51-54, 60-63, and 66-69 under 35 
U.S.C. § 103(a) as being unpatentable over Shroeder in view of Webber is erroneous for at 
least the following reasons. 

A. Independent Claims 1, 13, 27, 39, 49, 58, and 64 

Each of the independent claims 1,13, 27, and 39 recite a method, system, or software 
that, inter alia, (1) receives a standard data model, by a trading partner, comprising EDI 
related data for a plurality of transactions, (2) generates data definitions for a self-describing 
markup language which includes, for each transaction, (a) data definition for the self- 
describing markup language, (b) a separate data model to read in data, (c) a separate data 
model to read out data, and (d) a map component file; and (3) automatically generating, by 
the trading partner, an EDI document based on the self describing mark up language data. 
These recited features are not disclosed or suggested by the applied prior art. Therefore, these 
claims are directed to outbound processing whereby EDI documents are generated for sending 
to a trading partner based on the specific features (1) and (2) discussed above. 
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The final office action cites to Figure 4 and Paragraphs 51-52 of Shroeder for 
disclosing the distinctly claimed features 2(a)-2(d) above. However, these portions of 
Shroeder only discloses the use of a super map 402 for all possible data segments and data 
types for a given type of document. In contrast, the claimed features require that, for each 
transaction in standard data model (of the trading partner), a separate data model to read in 
data is created (for example, a Source XML model), a separate data model to read out data 
(for example, a Target EDI model), and a map component file. That is, Shroeder does not 
disclose the features recited in these independent claims. Rather Shroeder discloses a generic 
super map for a transaction type that is not generated from the standard data model (of the 
trading partner) and nor does Shroeder disclose the specific components 2(a)-(d) recited in the 
pending independent claims. 

The final office action cites to the XML document 404 as the data model to read in 
data. In reality, the XML document 404 is not a data model at all since it contains the actual 
data from the inbound data that is mapped by the inbound Supermap 402 to create the XML 
document 404. That is, Schroeder does not disclose that a separate source data model is 
created to read in data from which the XML document is subsequently created in conjunction 
with another separate data model to read out data in the format of the XML document. All 
the mapping that occurs to create the XML document 404 from the inbound data 400 is 
performed by the Inbound Supermap 402. Therefore, there is simply no disclosure in 
Shroeder of a separate data model to read in data or a separate data model to read out data 
wherein the read out data is formatted in the target format (either XML or EDI depending on 
whether inbound or outbound processing is being performed) . 

In order for a reference to be utilized as an anticipatory reference under the provisions 
of 35 U.S.C. § 102, the reference must disclose each and every claimed element. This is 
certainly not the case here, and thus the Sec. 102 rejection as to independent claims 1,13, 27, 
and 39 must be withdrawn. 

The independent claims 49, 58, and 64 recite a method, system, and software that 
process inbound EDI documents to generate data in a self describing data format from the 
received EDI documents. These claims also require for each transaction in a standard data 
model (of the trading partner), a separate data model to read in data is created (for example, a 
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Source EDI model), a separate data model to read out data (for example, a Target XML 
model), and a map component file. As discussed earlier herein, these separate data models 
allow for the automated generation of the self-describing markup language data and are also 
not disclosed or suggested by Shroeder. Therefore, these independent claims 49, 58, and 64 
are also not anticipated by Shroeder. 

Since the deficiencies of Shroeder are not cured by any of the other applied references, 
the Office Action fails to make a prima facie case of obviousness as required by 35 U.S.C. 
§103. Accordingly, the pending independent claims are patentable over the applied prior art. 

B. Dependent claims 2-5, 10-12, 14, 19-25, 28, 33-38, 44-48, 51-57, 60-63, and 

66-72 

Dependent claims 2-9, 11, and 12 depend from one of independent claims 1, 13, 27, 
39, 49, 58, and 64, and are allowable for at least the same reasons, as well as for further 
patentable features recited therein. 

For example, the dependent claims 2-5 disclose receiving user input of one or more of 
an EDI standard, a version of standard, or a transaction set which allows for the claimed data 
models to be customized. No such customized data models (for read in and read out data) are 
taught or suggested by Shroeder. In fact, Shroeder 5 s super map teaches away from this 
customization by teaching a super map that includes all the data segments and elements for a 
particular transaction. Furthermore, the cited figure 3 of Webber simply discloses a 
spreadsheet display but does not disclose the claimed user input of an EDI standard, a version 
of the standard, or a transaction set which allows for the claimed data models to be 
customized (and furthermore, the claimed data models are not disclosed either). Therefore, 
even if Webber is combined with Shroeder the specific features recited in claims 2-5 are not 
disclosed by either of these references or their reasonable combination. Accordingly, these 
recited features provide additional reasons for the patentability of these claims. 

II. It is respectfully submitted that the rejection of rejecting claims 13-14, 19-25, 
27-28, 33-38, 58, 60-64, and 66-72 under 35 U.S.C §101 as being directed to non-statutory 
subject matter is erroneous for at least the following reasons. 

The final office action alleges that "the language of claims 13, 58, and 73 describes a 
computer program per se." However, claims 13 and 58 recite a system (or apparatus) with 
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specified data models and computer implemented components (such as translators which use 
program code). Such system claims have been considered patentable under section 101 since 
the Supreme Court decision in 1981 (Diamond v. Diehr) and the number of cases at the 
Federal Circuit that have found such claims to be valid. The rejection of claim 73 is moot 
since claim 73 had already been cancelled in the prior reply. This rejection of claims 13 and 
58 is plainly erroneous and should be withdrawn. 

With respect to claims 27 and 64, the final office action alleges that there is apparently 
a question of whether these claims are directed to an abstract idea and not tied to a 
technological art. . ." First, as the PTO Board of Appeals noted in the Ex Parte Lundgren 
decision, there is no legal basis for the technological art requirement. Second, these claims 
recite a program code on a computer readable medium that is executed by a computer to 
perform the recited steps. Such a claim has been found to satisfy the requirements of section 
101 at least since the decision of the Federal Circuit in In re Beauregard, 53 F.3d 1583 
(1995) which stated that "computer programs embodied in a tangible medium such as floppy 
diskettes, are patentable subject matter under 35 U.S.C. §101...." Therefore, the examiner's 
continued speculation on the patentability of such claims has no basis in the law. 
Accordingly, this rejection is clearly erroneous and should be withdrawn. 

In this context, it should be noted that the final office action also alleges that the world 
"computer program product" is not defined in the specification. However, the term computer 
program product is a term of art that refers to computer programs on a computer readable 
medium and as such need not be defined in the specification just as the transition phrase 
"comprising" has a specific meaning in the claims and need not be separately defined in the 
specification. A simple search of the PTO website revealed that there were over 12,000 
issued patents that use the term "program product" in the claims. Therefore, the examiner's 
continued objections based on this term seems to be completely inconsistent with well 
established usage of terms in patent practice. 

Finally, it should be noted that the final office action states in paragraph 4 that claims 
1 and 1 1 have been rejected under 35 U.S.C. 102(e) as being anticipated by Yepishin. 
Neither this rejection nor the reference has been discussed anywhere else in this or any other 
office action. Accordingly, applicants assume that this rejection was inadvertently inserted in 
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the office action and does not require a response by the applicants. If this assumption is 
incorrect, clarification is requested. 

9. Conclusion 

In view of above, appellants respectfully solicit the Honorable Board of Patent 
Appeals and Interferences to reverse the rejections of the pending claims and pass this 
application on to allowance. 

Should additional fees be necessary in connection with the filing of this paper, or if a petition for extension of 
time is required for timely acceptance of same, the Commissioner is hereby authorized to charge deposit 
account No. 19-0741 for any such fees; and applicants hereby petition for any needed extension of time. 



Respectfully submitted, 



Date March 3, 2006 




FOLEY & LARDNER LLP 
Customer Number: 22428 
Telephone: (202) 672-5300 
Facsimile: (202) 672-5399 



William T. Ellis 
Registration No. 26,874 



Aaron C. Chatterjee 
Registration No. 41,398 



Attorneys for Applicants 
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10. EVIDENCE APPENDIX 

None 
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12. CLAIMS APPENDIX 
LIST OF THE PENDING CLAIMS (WITH STATUS IDENTIFIERS) 

1 . (Previously Presented) A computer implemented method of automatically 
generating Electronic Data Interchange (EDI) documents by a trading partner comprising the 
steps of: 

receiving, by the trading partner, a standard data model comprising EDI related data 
for a plurality of transactions; 

generating from the standard data model, by the trading partner, data definitions for a 
self-describing markup language corresponding to each transaction of the EDI related data; 

generating self-describing markup language data using a data definition from the 
generated data definitions for the self-describing markup language corresponding to an EDI 
transaction and corresponding application data related to EDI; and 

automatically generating, by the trading partner, an EDI document based on the self- 
describing markup language data, 

wherein the step of generating data definitions further comprises, for each transaction, 
generating data definitions for the self-describing markup language, a separate data model to 
read in data, a separate data model to read out data, and a map component file. 

2. (Original) The method according to claim 1, wherein the step of generating 
data definitions comprises receiving user input of an EDI standard, a version of the standard, 
a transaction set. 

3. (Original) The method according to claim 1, wherein the step of generating 
data definitions comprises receiving a user input of an EDI standard. 

4. (Original) The method according to claim 1, wherein the step of generating 
data definitions comprises receiving a user input of a version of a standard. 
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5. (Original) The method according to claim 1, wherein the step of generating 
data definitions comprises receiving a user input of a transaction set. 

6-9. (Cancelled) 

10. (Original) The method according to claim 1, wherein the generated EDI 
document conforms to an ANSI XI 2 standard. 

1 1 . (Original) The method according to claim 1, wherein the generated EDI 
document conforms to an UN EDIFACT standard. 

12. (Original) The method according to claim 1, wherein the self-describing 
markup language comprises extensible MarkUp Language (XML). 

13. (Previously Presented) A system for automatically generating Electronic Data 
Interchange (EDI) documents by a trading partner, the system comprising: 

a standard data model comprising EDI related data of a plurality of transactions; 

a computer implemented first generator that generates, from the standard data model, 
data definitions for a self-describing markup language corresponding to each transaction of 
the EDI related data; 

a computer implemented second generator that generates self-describing markup 
language data using a data definition for the self-describing markup language corresponding 
to an EDI transaction and corresponding application data related to the EDI; and 

a computer implemented translator that automatically generates an EDI document 
based on the self-describing mark up language data, 

wherein the first generator generates, for each of the plurality of transactions, data 
definitions for the self-describing markup language, a separate data model to read in data, a 
separate data model to read out data, and a map component file. 
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14. (Original) The system according to claim 13, wherein the self-describing 
markup language comprises XML and wherein the first generator is a Data Type Definition 
Generator (DTD Generator). 

15-18. (Cancelled) 

19. (Original) The system according to claim 13, wherein the first generator 
further comprises a user interface for user input of an EDI standard, a version of the standard, 
and a transaction set prior to generating the EDI document. 

20. (Original) The system according to claim 13, wherein the first generator 
further comprises a user interface for user input of an EDI standard prior to generating the 
EDI document. 

21. (Original) The system according to claim 13, wherein the first generator 
further comprises a user interface for user input of a version of the standard prior to 
generating the EDI document. 

22. (Original) The system according to claim 13, wherein the first generator 
further comprises a user interface for user input a transaction set prior to generating the EDI 
document. 

23. (Original) The system according to claim 13, wherein the generated EDI 
document conforms to an ANSI X12 standard. 

24. (Original) The system according to claim 13, wherein the generated EDI 
document conforms to an UN EDIFACT standard. 

25. (Original) The system according to claim 13, wherein the self-describing 
markup language comprises extensible MarkUp Language (XML). 
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26. (Cancelled) 

27. (Previously Presented) Program code on a computer readable medium, that is 
executable by a computer for generating Electronic Data Interchange (EDI) documents by a 
trading partner, the program code configured to cause the computer to perform the following 
steps: 

receiving, by the trading partner, a standard data model comprising EDI related data 
for a plurality of transactions; 

generating from the standard data model, by the trading partner, data definitions for a 
self-describing markup language corresponding to each transaction of the EDI related data; 

generating self-describing markup language data using a data definition from the 
generated data definitions for the self-describing markup language corresponding to an EDI 
transaction and corresponding application data related to EDI; and 

automatically generating, by the trading partner, an EDI document based on the self- 
describing markup language data, 

wherein the step of generating data definitions further comprises, for each transaction, 
generating data definitions for the self-describing markup language, a separate data model to 
read in data, a separate data model to read out data, and a map component file. 

28. (Previously Presented) The program code according to claim 27, wherein the 
self-describing markup language comprises XML and wherein the first generator comprises a 
Data Type Definition Generator (DTD Generator). 

29-32. (Cancelled) 

33. (Previously Presented) The program code according to claim 27, wherein the 
step of generating data definitions comprises receiving user input of an EDI standard, a 
version of the standard, and a transaction. 
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34. (Previously Presented) The program code according to claim 27, wherein the 
step of generating data definitions comprises receiving user input of an EDI standard. 

35. (Previously Presented) The program code according to claim 34, wherein the 
step of generating data definitions comprises receiving user input of the version of the EDI 
standard. 

36. (Previously Presented) The program code according to claim 27, wherein the 
generated EDI document conforms to the ANSI XI 2 standard. 

37. (Previously Presented) The program code according to claim 27, wherein the 
generated EDI document conforms to the UN EDIFACT standard. 

38. (Previously Presented) The program code according to claim 27, wherein the 
self-describing markup language comprises extensible MarkUp Language (XML). 

39. (Previously Presented) A computer implemented method of automatically 
generating Electronic Data Interchange (EDI) documents, by a trading partner, comprising the 
steps of: 

receiving, by the trading partner, a standard data model containing EDI related data 
for a plurality of transactions; 

receiving a manual entry of parameters related to an EDI document format; 

generating from the standard data model and the manual entry of parameters, by the 
trading partner, data definitions for the self-describing markup language corresponding to 
each transaction of the EDI related data and the received manually entered parameters; 

generating self-describing markup language data using the data definition for the self- 
describing markup language corresponding to an EDI transaction and corresponding 
application data related to EDI; and 

automatically generating, by the trading partner, an EDI document based on the self- 
describing markup language data, 
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wherein the step of generating data definitions further comprises, for each transaction, 
generating data definitions for the self-describing markup language, a separate data model for 
read in data, a separate data model for read out data, and a map component file. 

40-43 (Cancelled). 

44. (Original) The method according to claim 39, wherein the step of receiving a 
manual entry of parameters comprises receiving user input of an EDI standard, a version of 
the standard, a transaction set, and a direction. 

45. (Original) The method according to claim 39, wherein the step of receiving a 
manual entry of parameters comprises receiving user input of an EDI standard. 

46. (Original) The method according to claim 39, wherein the step of receiving a 
manual entry of parameters comprises receiving user input of a version of the EDI standard. 

47. (Original) The method according to claim 39, wherein the step of receiving a 
manual entry of parameters comprises receiving user input of a transaction set. 

48. (Original) The method according to claim 39, further comprising one data 
type definition for each transaction of each EDI standard used when generating EDI 
documents. 

49. (Previously Presented) A computer implemented method of automatically 
generating data in a self-describing markup language format from received EDI data, 
comprising the steps of: 

receiving EDI data from a component; 

retrieving a self-describing markup language data definition corresponding to a 
transaction type of received EDI data; and 
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automatically generating self-describing markup language data based on the received 
EDI data and the self-describing markup language data definition, 

prior to said receiving step, generating data definitions corresponding to each 
transaction type from a standard data model of EDI related data, 

wherein the generating data definitions step comprises, for each transaction, a data 
definition for the self-describing mark up language, a separate EDI data model to read in data, 
a separate self-describing mark up language data model to read-out data, and a map 
component file. 

50. (Cancelled) 

5 1 . (Original) The method according to claim 49, further comprising, prior to said 
retrieving step, receiving user input of an EDI standard, a version of the standard, and a 
transaction set in generating the self-describing markup language data definition. 

52. (Original) The method according to claim 49, further comprising, prior to said 
retrieving step, receiving a user input of an EDI standard in generating the self-describing 
markup language data definition. 

53. (Original) The method according to claim 52, further comprising, prior to said 
retrieving step, receiving a user input of a version of the EDI standard in generating the self- 
describing markup language data definition. 

54. (Original) The method according to claim 49, further comprising, prior to said 
retrieving step, receiving a user input of a transaction set in generating the self-describing 
markup language data definition. 

55. (Original) The method according to claim 49, wherein the received EDI data 
conforms to the ANSI XI 2 standard. 
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56. (Original) The method according to claim 49, wherein the received EDI data 
conforms to the UN EDIFACT standard. 

57. (Original) The method according to claim 49, wherein the generated self- 
describing markup language comprises extensible MarkUp Language (XML). 

58. (Previously Presented) A system for automatically generating data in a self- 
describing markup language format from received EDI data, the system comprising: 

a component for transmitting EDI data; 

a translator that receives a self-describing markup language data definition 
corresponding to a transaction type of received EDI data; 

wherein the translator that automatically generates the self-describing markup 
language data based on the received EDI data and the self-describing markup language data 
definitions, 

wherein the receiver receives the self-describing markup language data definition 
generated by a generator from a standard data model comprising EDI related data for a 
plurality of transactions, the data definition comprising, for each transaction, a data definition 
for the self-describing mark up language, a separate EDI data model to read in data, a separate 
self-describing mark up language data model to read-out data, and a map component file. 

59. (Cancelled) 

60. (Original) The system according to claim 58, wherein the generator further 
comprises a user interface for user input of an EDI standard, a version of the standard, and a 
transaction set prior to generating the self-describing markup language format. 

61. (Original) The system according to claim 58, wherein the generator further 
comprises a user interface for user input of an EDI standard prior to generating the self- 
describing markup language format. 
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62. (Original) The system according to claim 61, wherein the generator further 
comprises a user interface for user input of a version of the EDI standard prior to generating 
the self-describing markup language format. 

63. (Original) The system according to claim 58, wherein the generator further 
comprises a user interface for user input of a transaction set prior to generating the self- 
describing markup language format. 

64. (Currently Amended) A program code on a computer readable medium that is 
executable by a computer for automatically generating data in a self-describing markup 

language data from received EDI data, the program code configured to cause the computer to 

') 42 

perform the following steps: 

receiving EDI data from a component; 

retrieving a self-describing markup language data definition corresponding to a 
transaction type of received EDI data; and 

automatically generating self-describing markup language data based on the received 
EDI data and the self-describing markup language data definition, 

prior to said receiving step, generating data definitions corresponding to each 
transaction type from a standard data model comprising EDI related data for a plurality of 
transactions, 

wherein the generating data definitions step comprises, for each transaction, a data 
definition for the self-describing mark up language, a separate EDI data model to read in data, 
a separate self-describing mark up language data model to read-out data, and a map 
component file. r 

65. (Cancelled) 

66. (Previously Presented) The program code according to claim 64, further 
comprising, prior to said retrieving step, receiving user input of an EDI standard, a version of 
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the standard, and a transaction set in generating the self-describing markup language data 
definition. 

67. (Previously Presented) The program code according to claim 64, further 
comprising, prior to said retrieving step, receiving user input of an EDI standard in generating 
the self-describing markup language data definition. 

68. (Previously Presented) The program code according to claim 67, further 
comprising, prior to said retrieving step, receiving user input of the version of the EDI 
standard in generating the self-describing markup language data definition. 

69. (Previously Presented) The program code according to claim 64, further 
comprising, prior to said retrieving step, user input of a transaction set in generating the self- 
describing markup language data definition. 

70. (Previously Presented) The program code according to claim 64, wherein the 
received EDI data conforms to the ANSI XI 2 standard. 

71 . (Previously Presented) The program code according to claim 64, wherein the 
received EDI data conforms to the UN EDIFACT standard. 

72. (Previously Presented) The program code according to claim 64, wherein the 
generated self-describing markup language comprises extensible MarkUp Language (XML). 

73. (Cancelled). 
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